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Abstract 


We present TEP, a system that supports 
general-purpose shared computation between 
mutually-distrusting parties. TEP is useful for 
applications, such as auctions and tax prepara- 
tion, that use private information from multi- 
ple participants. Such applications cannot be 
run on any one participant’s computer without 
sacrificing the other participants’ privacy. TEP 
acts as a trusted service that hosts the sensitive 
parts of such applications. 


TEP uses a Java VM to load and run com- 
putations on behalf of clients. TEP uses Java 
security mechanisms and cryptographic proto- 
cols to ensure that (1) a program can commu- 
nicate only with the specific participants identi- 
fied for a computation and (2) each participant 
knows exactly what program is being run and 
who the other participants are. This lets partic- 
ipants determine whether information they send 
to the computation can be exposed to other par- 
ticipants; we show how static analysis greatly 
simplifies this task. Example programs show 
that the TEP model is useful and easy to pro- 
gram; benchmarks show that the TEP prototype 
implementation is fast enough to be practical. 
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1 Introduction 


Sharing private data in a computation presents 
a paradox. How can two parties combine their 
private data in a computation without revealing 
their data to one another? Many systems, such 
as online auctions, solve this problem by intro- 
ducing a trusted third party to run the compu- 
tation. However, such systems are usually spe- 
cialized to a single application and provide only 
vague guarantees on the system’s ability to con- 
trol information leaks. This paper presents the 
Trusted Execution Platform (TEP), a new sys- 
tem that supports general-purpose multiparty 
computation with specific guarantees on infor- 
mation leaks. 

Consider an online tax-preparation applica- 
tion called “WebTax”. WebTax uses a propri- 
etary database provided by a tax preparer and 
requires private income data from the client. If 
WebTax runs on a computer controlled by ei- 
ther the client or the preparer, the privacy of 
the other party’s data is compromised. Run- 
ning WebTax on TEP protects the privacy of 
both parties. 

There are two general types of difficulties that 
might afflict a trusted third-party computation 
service. First, the third party might turn out 
not to be trustworthy, due to either malice or 
incompetence. We have nothing new to offer 
here. We assume that TEP is trustworthy and 
simply guarantee that users of TEP can authen- 
ticate their connections to TEP. 

The second type of difficulty arises when the 
participants in a shared computation try to 
trick each other. A participant might not realize 


that a shared computation’s algorithms reveal 
its data to another participant. A participant 
might be misled about what computation it is 
participating in; for example, it might submit a 
bid to the wrong auction. A participant might 
understand the computation involved, but be 
mistaken about who else is participating. A 
participant might understand the computation 
and know the participants, but be misled about 
the role of each participant. Any of these er- 
rors could result in undesired exposure of pri- 
vate data, even if TEP is completely trustwor- 
thy. 

The key to avoiding these errors is thorough 
identification. TEP provides enough informa- 
tion to each participant to allow a precise un- 
derstanding of whom the participant’s private 
data may be exposed to. TEP identifies spe- 
cific properties about each computation to every 
participant involved in that computation: 


TEP authentication of TEP itself 


Program the exact bytecodes of the program 
used for a computation 


Participants the participants in a computa- 
tion 


Roles the role each participant plays in the 
computation 


Instance distinguishes between computations 
with the same program, participants, and 
roles. 


To make these properties meaningful, TEP 
must guarantee that data used in a computation 
cannot escape through unidentified channels: 


Isolation Ensure that data given to a program 
cannot leak to parties that are not partici- 
pants. 


Although TEP can prevent data from being ex- 
posed to non-participants, it is still up to each 
user to determine whether a program leaks his 
or her information to legitimate participants. 
Doing this requires inspection of the code. This 
inspection process is likely to be tedious and er- 
ror prone, so we explain how inspection can be 


automated using static information-flow analy- 
sis. 

Section 2 presents a design for TEP that pro- 
vides the required identification and isolation. 
Section 3 details how the design is implemented. 
Section 4 describes how TEP incorporates static 
analysis, and Section 5 presents performance re- 
sults for a prototype implementation. Finally, 
Section 6 discusses related work, and Section 7 
concludes. 


2 Design 


This section describes how TEP satisfies its 
identification and isolation requirements. The 
design uses a “call back” model, in which a 
computation is invoked with a set of parameters 
that identify the participants. The computation 
initiates connections to the participants speci- 
fied in the parameters. Participants run trusted 
local agents that accept connections from com- 
putations on TEP and handle the necessary au- 
thentication and policy decisions on their par- 
ticipant’s behalf. 

An alternate model is to allow participants to 
initiate connections to computations on TEP. 
This has the convenience of following the stan- 
dard client-server model and allowing partic- 
ipants to join long-running computations dy- 
namically. However, this adds complexity to 
TEP, since TEP must forward incoming con- 
nections to the correct computations. We plan 
to support this model in future work. 

All communication between a computation 
running on TEP and the participants in the 
computation occurs through channels. A chan- 
nel is a bidirectional communication connection 
between a program on TEP and a participant. 
A program on TEP can only communicate with 
participants using channels, which allows TEP 
to authenticate each source and sink for the 
data used in the computation. 


2.1 TEP Identification 


Whenever TEP opens a channel to a partici- 
pant, it carries out a two-way authentication 


protocol in which it identifies itself to the par- 
ticipant. This allows the participant to be cer- 
tain that it is communicating with TEP. We as- 
sume that participants can find the public key 
for TEP from a key distribution authority. 


2.2 Program Identification 


To identify a program, TEP creates a finger- 
print of the program bytecodes. The fingerprint 
is calculated using a cryptographic hash of the 
bytecodes in a canonical order. Given this fin- 
gerprint, a participant can determine (with high 
probability) what program is running on TEP 
and so base its decision about whether to par- 
ticipate on local knowledge about that program. 


2.3. Participant Identification 


Each participant is identified by a public key, 
which it uses to authenticate itself when TEP 
opens a channel to it. TEP checks that this key 
matches the one for the expected participant for 
that channel. 


2.4 Role Identification 


In any computation, a participant plays a par- 
ticular role. A role is a name for the part 
a participant plays in a computation, such as 
client or bidder. Each channel specifies a role 
for the participant it connects to; a participant 
can refuse the connection if the role isn’t what 
it expects. Additionally, roles help users under- 
stand how their data is used in the computation, 
since there will typically be a direct connection 
between a role and a program variable. 


2.5 Instance Identification 


It is possible that multiple computations with 
the same program, participants, and roles are 
running on TEP simultaneously. To distinguish 
these instances, TEP assigns each computation 
an instance identifier. This identifier is a nonce: 
a new value that, with high probability, is dif- 
ferent from the identifier for any other computa- 
tion with the same program, participants, and 
roles. This identifier can be used to identify the 


computation and its results after the fact, e.g., 
in an auditing procedure. 


2.6 Isolation 


TEP must ensure that data used in a compu- 
tation does not leak to any parties outside that 
computation. This requires that TEP restrict a 
program’s behavior in a few ways. First, TEP 
restricts all program input and output to chan- 
nels, so that TEP can intervene before any data 
enters or leaves the system. Furthermore, all 
communication over these channels is encrypted 
and authenticated to prevent eavesdropping and 
impersonation. 

Next, since TEP is a multi-process system, 
TEP must isolate the data areas and name 
spaces for concurrent programs from one an- 
other. 

TEP must also ensure that programs cannot 
corrupt TEP’s own process or access system 
resources directly, since this might allow pro- 
grams to circumvent TEP’s protection mecha- 
nisms. TEP denies programs direct access to 
the network, disk, and runtime system, since 
access to any of these could allow programs to 
leak data or attack on TEP directly. This means 
programs cannot store any persistent state on 
TEP between invocations. This is usually ac- 
ceptable, since programs can send intermediate 
results to participants over channels and read 
them back later. 


3. Implementation 


This section describes how TEP’s design can be 
implemented efficiently. 

Programs for TEP are written in Java. Java 
provides many features that make the imple- 
mentation straightforward, such as type safety 
(backed up by bytecode verification) and the 
ability to load code dynamically [7]. 

An example of a Java program for TEP is 
given in Figure 1. WebTax is a tax prepara- 
tion application with two participants: a client 
that provides private income data and a tax pre- 
parer that provides a proprietary tax database. 


WebTax reads data from both participants, cal- 
culates the client’s tax, and writes the result 
back to the client. This section will refer to this 
example as each new concept is introduced. 


3.1 Code Structure 


Any program that can be run by TEP must pro- 
vide exactly one run method. The run method 
must be public and static, return void, and 
throw no exceptions. This ensures that TEP 
can invoke the run method and that TEP need 
not provide any specific information on to the 
participants how the the method terminates. 

Additionally, the parameters of the run 
method are limited to the type Participant; 
we discuss this type further below. For example, 
WebTax takes two participants as arguments, 
the client and the tax preparer. 


3.2 Invocation 


Anyone can invoke a computation on TEP by 
specifying a URL for the program, a fingerprint 
for the bytecodes, and a set of participant bind- 
ings. Say a client with key Kc wants to invoke 
WebTax for a tax preparer with key Kp. The 
client must provide TEP with a URL for Web- 
Tax, a fingerprint for the code, and a role, host, 
port, and key for itself and the tax preparer 
(presented here in an XML format): 


<Invocation url="http://tax.com/app. jar" 
md5-hash="Livqv6VrqBk50VCXTdhOQUA=="> 
<Participant role="client" 
host="host-c.domain.com" 
port=1234 
key=Ke /> 
<Participant role="preparer" 
host="server.tax.com" 
port=6060 
key=Kp /> 
</Invocation> 


Typically, the user does not need to provide 
this information directly. For example, the tax 
preparer might have a web site that would al- 
low a client to sign up for tax preparation by 
filling out a form. Then the form would be pro- 
cessed automatically to provide the invocation 
description and send it to TEP. 


When TEP receives an invocation request, it 
fetches the WebTax application from the URL 
and checks that it matches its fingerprint. Then 
it runs the bytecode verifier on every class in the 
entire application. If either of these fails, TEP 
refuses the request. 

TEP then looks for WebTax’s run method. 
The number of participants in run’s signature 
must match the number of participants specified 
by the invoker. Given the above computation 
request, WebTax’s run method must have this 
signature: 
public static void run(Participant, 

Participant) ; 
the invocation request is incompatible with the 
method signature, TEP refuses the request. 

TEP next creates objects that represent the 
participants: one for each participant in the re- 
quest. TEP then runs the application, passing 
it the Participant objects in the order speci- 
fied in the invocation request. 

The participant objects are of type 
Participant, which is a Java class that 
is provided by TEP for use in programs that 
will run on TEP. Each Participant contains a 
role, host, port, and key: 


public class Participant { 
final public String role; 
final public String host; 
final public int port; 
final public PublicKey key; 
Participant (String role, 
String host, 
int port, 
PublicKey key); 


Participant is an immutable type that has a 
package visible constructor. This means that 
only TEP’s code can create Participant ob- 
jects. Programs on TEP use participants for 
channel creation, as explained in the next sec- 
tion. 

To support variable numbers of participants, 
TEP provides the ability to create an array of 
participants that share the same role. For exam- 
ple, say participants with keys Ka and Kb wish 
to bid in an auction. Each participant can fill 
out a form to provide an auction site with their 
host, port, and key information (this is not a 


public class WebTax 
{ 


public static void run(Participant clnt, Participant prep) 


{ 
try { 
// read client’s income data 


Channel clientChan = new Channel (clnt) ; 


Income income = new Income(clientChan. getInputStream()) ; 


//get tax preparer’s channel 
Channel prepChan = new Channel (prep) ; 


// calculate taxes 
Tax tax = calcTax(income, prepChan) ; 


// send tax to the client 


tax.writeTo(clientChan. getOutputStream()) ; 


} catch (Exception e) { 
// ignored 


Figure 1: WebTax Java Code 


serious privacy risk since the agents running at 
the participants can filter out any unsolicited 
computations). The auction site then invokes 
the auction on TEP with the command: 


<Invocation url="http://tbay.com/app.jar" 
md5-hash="6P jqrrxv6yitwOYDMdpROA==" 
app-ident="1997 Ford Explorer"> 
<Participant role="auctioneer" 
host="tbay.com" 
port=7070 
key=Kt /> 
<ParticipantArray role="bidder"> 
<Participant host="host-a.domain.com" 
port=1234 
key=Ka /> 
<Participant host="host-b.domain.com" 
port=4321 
key=Kb /> 
</ParticipantArray> 
</Invocation> 


In an auction, many participants fill the same 
role (bidder). This is represented in the re- 
quest as a list of participants nested under a 
ParticipantArray element that specifies the 
role. The corresponding run method for this 
request is: 


public static void run(Participant, 
Participant []); 


Another point about this example is that the 
invocation description includes an application 
identifier. The app-ident field allows the in- 
voker to provide an uninterpreted string that 
can be used in an application-specific way. In 
this case, it is being used to identify the par- 
ticular auction being run. While this field isn’t 
strictly necessary, it can be useful to allow an 
application to easily distinguish different com- 
putations that use the same program. The ap- 
plication identifier field is separate from the in- 
stance identifier assigned by TEP. 


3.3. Channels 


TEP provides programmers with an API for cre- 
ating and using channels. The implementation 
of this API is stored on TEP and linked with 
a program when it is loaded. The API defines 
one class, Channe1: 


public class Channel { 
public Channel(Participant p) 
throws AccessControlException, 


GeneralSecurityException, 
IOException; 
public Participant getParticipant() ; 
public InputStream getInputStream() ; 
public OutputStream getOutputStream() ; 
} 


Channel contains four instance methods: a 
constructor and three accessors. A program cre- 
ates a channel by calling the constructor with a 
Participant as an argument. The constructor 
opens a secure connection to the given partici- 
pant and throws an exception if an error occurs. 
getParticipant provides access to the partic- 
ipant used to create the channel. The other 
accessors provide access to the channel using 
the standard Java input and output stream ab- 
stractions [8]. TEP’s underlying implementa- 
tion of these streams provides secure informa- 
tion transfer. 

TEP creates a channel as follows: 


1. connects to p.host and p.port, where p 
is the Participant passed to the channel 
(throws an IOException if this fails) 


2. authenticates the channel and checks that 
the peer’s public key matches p.key 
(throws an AccessControlException if 


this fails) 


3. uses encryption and message authentica- 
tion codes (MACs) to protect the channel’s 
privacy and integrity (throws a General- 
SecurityException if this fails) 


4. sends the computation information (the 
program fingerprint, the application iden- 
tifier, this channel’s participant, the other 
participants, and the instance identifier) to 
the peer in a format similar to the one for 
invoking a computation 


The required authentication and encryption can 
be implemented using any secure session proto- 
col, such as SSL [21]. 

The peer checks that it is connected to the 
correct program and that its role is what it ex- 
pects; it disconnects if not. The peer may also 
check the application identifier and the other 
participants; for example, the client of WebTax 


may check to be sure that the other participant 
is the tax preparer it expects. If TEP receives 
no response from the participant, it times out 
and throws an IOException to the program. 


3.4 Example: WebTax 


The Java code for WebTax is presented in Fig- 
ure 1. WebTax defines a run method, which 
is the top-level method invoked by TEP. When 
TEP receives a computation request for Web- 
Tax, it creates two Participant objects, one 
for the client and one for the tax preparer. 

WebTax creates a channel to the client using 
the first participant. If the channel is created 
successfully (i-e., the agent acting as the client 
accepts the channel), WebTax reads the client’s 
income data by constructing an Income object 
from the channel’s input stream. Income is a 
class included with WebTax that knows how to 
read its value from a Java InputStream. 

Next WebTax creates a channel to the tax 
preparer and calls the method calcTax to calcu- 
late the client’s tax. This method uses the pre- 
parer’s channel to read the preparer’s database 
and uses that information along with the client’s 
income data to compute the taxes. Finally, 
WebTax writes the result to the client’s output 
stream by calling the result’s writeTo method 
on the client’s output stream. 

This program leaks data. Since the client’s 
tax incorporates information read from the pre- 
parer’s database, some amount of the preparer’s 
private information is leaked to the client. This 
is presumably acceptable for the tax preparer 
(or the program would not have been made 
available for general use), and without this leak 
no useful computation can be shared. Section 4 
will show how static analysis can detect such 
leaks. 


3.5 Example: Auction 


The Auction example in Figure 2 implements a 
silent auction for a set of bidders. This applica- 
tion is invoked with two types of participants: 
a single auctioneer and a set of bidders. The 
auctioneer invokes the auction and identifies the 


item up for bid by setting an application identi- 
fier. The auctioneer also sets the reserve price. 
The bidders each check the application identi- 
fier to confirm they are in the correct auction, 
send in a bid, then read the winning bid at the 
end of the auction. 

First, the program connects to the auctioneer. 
If this fails, the program exits, since there is no 
reason to continue (it could also contact each 
bidder to report the error). The program then 
uses the channel to read the reserve price. 

Next, the program creates a channel for each 
bidder. If the bidder discovers that it is in the 
wrong auction, it refuses the connection. In this 
case, the program will get an IOException and 
continue to the next bidder. After all the bids 
have been read and the winning bid has been 
calculated, the program reports the winning bid 
to each bidder. 


3.6 Policies 


When a computation connects to a participant, 
TEP provides the participant with enough in- 
formation to determine whether that computa- 
tion can leak the participant’s data. Each par- 
ticipant decides independently whether to par- 
ticipate in a computation according to its own 
local security policies. 

Since policies are local, participants can au- 
tomate policy processing using a policy en- 
gine [23]. A policy engine can answer queries 
about policy and, given a computation, de- 
cide whether the participant should partici- 
pate. These decisions might consider whether 
the computation can leak the participant’s data 
and, if so, whether the participant considers the 
leak acceptable. 

By automating the approval process, policy 
engines enable participants to connect their own 
programs to TEP over channels. Typically, a 
particular shared computation will require a 
specialized client-side agent to interact with the 
computation, and that agent acts as the policy 
engine for that computation. For example, an 
agent for WebTax accepts a connection from a 
computation on TEP and checks that the com- 
putation has the correct parameters. 


A client-side agent might help a participant 
“sign up” for a group computation, such as an 
auction, and then wait for a connection from 
TEP. When TEP connects to the agent, the 
agent checks that the computation is using the 
correct bytecodes and that it is bound to the 
correct channel. The agent might also check 
the bindings for the other participants in the 
computation. 

A participant must trust its agent, since the 
agent has access to the participant’s local data. 
This is a serious risk, since an agent could reveal 
the participant’s data directly to other parties 
on the network. To alleviate this risk, TEP pro- 
vides the TepAgent class: 


public class TepAgent { 
public TepAgent (KeyPair localKeys) ; 
public Invocation getInvocation() ; 
public InputStream getInputStream() ; 
public OutputStream getQutputStream() ; 
BS 


When constructed, TepAgent waits for a con- 
nection from a computation on TEP, authen- 
ticates TEP, authenticates itself to TEP using 
the local participant’s keys, and reads the invo- 
cation information from the connection. Tep- 
Agent provides accessors for the invocation in- 
formation and the connection to the computa- 
tion. Invocation is a Java type that provides 
the same information used to invoke the com- 
putation. 

Application-specific agents can be built on 
top of TepAgent. Participants can then deny 
application agents direct access to the network 
(using Java-style security policies [10]), since 
those agents should only communicate to TEP 
using TepAgent. TepAgent can provide addi- 
tional protection mechanisms, such as request- 
ing direct participant approval of a computa- 
tion. Since there can be more than one TEP 
server, each server should provide a signed im- 
plementation of TepAgent (or an appropriate 
certificate) that will properly authenticate that 
server. 


3.7 Isolation 


TEP must isolate programs from each other 
to ensure they cannot share data outside their 


public class Auction 


{ 


} 


public static void run(Participant a, Participant bs[]) 


‘i 


I 


try { 
// create a channel to the auctioneer and 
// read the reserve price 
Channel auctionChan = new Channel("auctioneer", a); 
Bid reserve = new Bid(auctionChan.getInputStream()) ; 
Bid max = reserve; // the current max bid 

} catch (Exception e) { 
return; // bad auctioneer: unrecoverable 


} 


// create an array of channels for the bidders 
Channel bidChans[] = new Channel [bs.length] ; 


// open a channel to each bidder and read each bid, 
// updating max as needed 
for (int i = 0; i < bs.length; i++) { 
try { 
bidChans[i] = new Channel("bidder", bs[i]); 
Bid bid = new Bid(bidChans [i] .getInputStream()) ; 
if (bid.value > max.value) max = bid; 
} catch (Exception e) { 
continue; // bad bidder: move on to the next one 
} 
} 


// send the winning bid to each bidder 
for (int i = 0; i < bs.length; it+) { 
try { 
max.writeTo(bidChans [i] .getOutputStream()) ; 
} catch (IOException e) { /* ignored */ } 
} 


Figure 2: Auction Java Code 


channels. TEP must also prevent programs 
from accessing system resources directly, since 
otherwise programs could use the disk or the 
network to leak data. TEP implements these 
measures using specific features of Java: type 
safety, classloaders, and security managers. 

TEP must ensure the memory safety of each 
program. A number of techniques have been 
developed to isolate dynamically-loaded code 
(22, 18, 16]. TEP depends on Java’s type safety 
to provide this protection. 

TEP runs each program in its own thread 
in TEP’s Java virtual machine (JVM). TEP 
creates a new instance of a custom Java class- 
loader for each program. This classloader pro- 
vides each program with its own class names- 
pace and static data area [11]. The classloader 
only allows a program to load the TEP-provided 
classes Channel and Participant and the ap- 
plication classes that are included in the pro- 
gram’s JAR file [9]. Java classloaders provide a 
form of name space management that prevents 
programs from accessing each other’s code and 
data [23]. This allows multiple copies of the 
same program to execute independently in the 
same JVM. 

TEP uses Java’s security manager to deny 
programs direct access to system resources, such 
as the Java runtime environment, the disk, and 
the network [10]. This prevents programs from 
circumventing TEP’s channel API and ensures 
that TEP can intervene before any data leaves 
the system. This also protects TEP’s own code 
from attack by the programs it runs. Although 
these mechanisms suffice, other research has ex- 
plored providing much stronger process isola- 
tion in Java [3]. 

TEP does not use any resource allocation 
scheme to protect programs from CPU or net- 
work starvation. Although unnecessary for 
privacy, such a scheme is needed to protect 
TEP and the programs it runs against denial- 
of-service attacks. Adding resource control 
would require that programs include informa- 
tion about their resource needs and would re- 
quire that TEP either monitor programs’ re- 
source consumption [18] or check them stati- 
cally [16]. 


Finally, TEP makes no claims on covert chan- 
nels, such as timing channels. However, static 
information-flow analysis will allow TEP to de- 
tect implicit information flows in the control 
structure of a program, as discussed in Sec- 
tion 4. 


3.8 Extensions 
3.8.1 Auditing 


Even though TEP identifies each computation 
to the participants, participants might disagree 
about the result of a computation (for exam- 
ple, the winner of an auction or the item up for 
bid). The solution to this problem is auditing: 
keeping logs of computations for use in settling 
future disputes. 

TEP can act as a trusted auditor by record- 
ing all data sent to a program over each chan- 
nel. Provided programs are deterministic, TEP 
can “replay” a recorded program by simulating 
the channels. To ensure deterministic behavior, 
TEP must deny program access to all sources 
of nondeterminism, such as the system clock. 
This is not a serious limitation since such in- 
formation can be provided by participants over 
channels (and so logged by TEP). To match au- 
dit logs with particular computations, partici- 
pants need only provide the instance identifier 
assigned by TEP for that computation. 

Keeping audit logs places a heavy load on 
TEP and introduces the risk that TEP might 
leak the logs, since they must be stored for an 
extended period of time. A solution is for TEP 
to encrypt a computation’s logs once the com- 
putation is complete and store the encrypted 
logs in a reliable offline database. The compu- 
tation information must be public for indexing, 
but the privacy of the logs themselves is pro- 
tected by encryption. 


3.8.2 Using a PKI for Role Bindings 


In TEP, each computation has its own bindings 
from participant’s roles to keys. This relation 
maps naturally to name-key bindings in a public 
key infrastructure (PKI), such as PKIX (X.509) 
[17] or SPKI [19]. Instead of inspecting the role 


bindings for a computation at runtime, partici- 
pants can create role bindings before a compu- 
tation by issuing the appropriate certificates. 

Using a PKI, an invocation no longer needs 
to include keys in the role bindings. Instead, 
an invocation needs to identify the root naming 
authority. This is the public key of the certifi- 
cation authority (CA) that issues the role-key 
bindings for the computation. 

When a computation opens a channel, TEP 
verifies that the peer’s key is bound to the chan- 
nel’s role by certificates issued by the root CA. 
TEP sends the root CA key to each participant 
along with the other computation information, 
so each participant can verify that TEP is using 
the correct bindings. 

This structure has the benefit of simplifying 
participants’ computation approval process at 
runtime, since each participant need only check 
the root CA key [1]. A drawback is that TEP 
must now verify role-key bindings when chan- 
nels are created. If this involves searching a 
PKI, this can be very slow. Another issue is that 
a PKI is less flexible than including role bind- 
ings with each computation, since certificate 
propagation and revocation can take time. This 
is a drawback when bindings need to change of- 
ten. 

A solution to both these problems is to in- 
clude the required certificates with the invo- 
cation, as in proof-carrying authentication [2]. 
Role bindings can be represented as chains of 
name certificates in SDSI/SPKI-style linked lo- 
cal name spaces; these chains must be provided 
to TEP when the computation with those bind- 
ings is invoked. This alternative still requires 
that TEP verify the proofs of each property; 
but this may be faster than requiring that each 
participant individually approve the bindings. 

A client using a PKI can invoke WebTax with 
these parameters: 
<Invocation url="http://tax.com/app. jar" 

md5-hash="Livqv6VrqBk50VCXTdhOQUA==" 
root-—key=kr> 
<Participant role="client" 
host="host-c.domain.com" 
port=1234 /> 
<Participant role="preparer" 
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host="server.tax.com" 
port=6060 /> 
<Proof role="client" key=Kc> 


<!-- sequence of certificates --> 
</Proof> 
<Proof role="preparer" key=Kp> 
<!-- sequence of certificates --> 
</Proof> 
</Invocation> 


The top-level element specifies the root CA 
key with the root-key attribute. The partici- 
pant elements no longer specify keys, since the 
role-key bindings are specified by certificates 
in the PKI. This invocation include proofs for 
these bindings, so TEP doesn’t need to search 
the PKI for them. TEP sends this information, 
except for the proofs, to each participant in the 
computation. Given just the root CA key, the 
participants can determine whether TEP is us- 
ing the correct bindings for the computation. 


3.8.3. Anonymous Participants 


Not all participants may want to be identified 
to every other participant. In an auction, bid- 
ders’ identities are irrelevant to the computa- 
tion, and a bidder may want hide its identity 
for a given auction. TEP can support this with 
anonymous participants: the invoker of a pro- 
gram can mark certain participants as anony- 
mous, which means their public key, host, and 
port will not be sent to the other participants. 
However, TEP will report to each participant 
the number of anonymous participants in each 
role. This allows a participant to refuse to par- 
ticipate in a computation where roles should not 
be anonymous, such as the tax preparer in Web- 
Tax. 


4 Information Flow Analysis 


As described so far, TEP allows computations 
to share data with participants without leaking 
their data. But there is a major problem: how 
does a participant decide whether the program 
being run leaks his or her data? The only way 
this can be done so far is for the participant 
to carefully inspect the code. Unfortunately, 


inspection is tedious and error-prone, especially 
as programs become more complex. 


For example, a client of WebTax would need 
to examine the code to be sure that his or her 
income information is not leaked to the tax pre- 
parer. This would require reading the code of 
the calcTax method and all the code it calls. 
This may very well be a huge program, so read- 
ing it and understanding whether it leaks infor- 
mation is a formidable undertaking. Further- 
more, the code may be proprietary: the tax 
preparer may not want to allow the code to be 
read. 


The solution to this problem is_ static 
information-flow analysis. This analysis checks 
a program at compile-time for information 
leaks. Any information that a program leaks 
must be explicitly declassified; the participant 
whose data is leaked must explicitly authorize 
that leak. For example, the tax preparer must 
authorize WebTax. The client, however, knows 
that it does not authorize WebTax, and so does 
not need to inspect the code (which also pro- 
tects the tax preparer’s privacy interests for the 
code). 


Static analysis tracks not only explicit in- 
formation flows through direct computation, 
but also implicit flows through the control flow 
of a program. For example, the statement 
if (secret) channel.write(true) leaks the 
value of secret. Static analysis catches this 
leak and makes it possible to find leaks that 
would be extremely difficult to find by inspec- 
tion. 


TEP supports static information-flow analy- 
sis using Myers’ Java information flow language, 
Jif [15, 14]. Jif extends Java with decentral- 
ized information-flow labels, a type of annota- 
tion that converts information flow analysis to 
an extended form of type-checking. A Jif com- 
piler or bytecode verifier can efficiently analyze 
a labelled Jif program to determine whether it 
leaks any data without explicitly declassifying 
it, and will reject the program if it does [14, 12]. 
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4.1 Labels 


Jif labels are annotations on the type of a vari- 
able that represent the privacy policies for that 
variable. Labels contain policies owned by prin- 
cipals, which are named entities that embody 
some authority in a program. Jif defines an or- 
dering on labels that prevents data with a given 
label from being written to a variable with a less 
restrictive label, and so prevents data from be- 
ing leaked as it moves between variables in a 
program. 

Jif allows the roles in a computation to be 
captured directly in labels. In particular, a par- 
ticipant’s role will be captured by the label on 
the Participant object created for that user. 
For example, the client’s participant in Web- 
Tax would have type Participant{client: }. 
This label means that the labeled data item is 
readable only by the client. Jif labels have a far 
richer structure than shown here, but TEP does 
not use anything more. 

To illustrate the power of Jif, the Jif version 
of WebTax is presented in Figure 3. The first 
thing to note is the use of labels in the header of 
the run method to capture the roles of the two 
participants. This header indicates that there 
are two principals involved in running the pro- 
gram, one representing the client, and the other, 
the tax preparer. 

The next thing to notice is the use of chan- 
nels. In Jif, channels are parameterized by 
the principal of the participant that will be 
using that channel. Such a channel restricts 
the labels of data that can be read and writ- 
ten to the channel, namely to have the label 
{principal:}. Thus the channel to the client 
will produce data labeled {client:} and will 
also only accept data labeled {client:}. Sim- 
ilarly the channel produced for the tax pre- 
parer produces and accepts only data with the 
label {preparer:}. Note that this prevents 
the client’s data from being written to the pre- 
parer’s channel and vice versa. 

The tax computation produces a result that 
has a compound label {client:, preparer: }, 
since the result involves data from both par- 
ties. This result cannot be written to the client’s 


public class WebTax authority (preparer) 
{ 
public static void run(Participant{client:} clnt, Participant{preparer:} prep) 
where authority (preparer) 


{ 
try { 
// read client’s income data 
Channel[client] clientChan = new Channel[client] (clnt) ; 
Income{client:} income = new Income(clientChan.getInputStream()) ; 
//read preparer’s tax database 
Channel [preparer] prepChan = new Channel [preparer] (prep) ; 
// calculate taxes 
Tax{client:, preparer:} tax = calcTax(income, prepChan) ; 
// send tax to the client 
declassify(tax, {client:}) .writeTo(clientChan. getOutputStream()) ; 
} catch (Exception{client:} e) { 
// ignored 
} catch (Exception{preparer:} e) { 
// ignored 
} 
} 
} 


Figure 3: WebTax Jif Code 
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channel since its label doesn’t match what the 
channel requires. 

To handle this case, Jif allows data to be de- 
classified. However, a program can declassify 
data only if it runs with the authority of the 
principal in the label being removed. WebTax 
runs with the authority of the tax preparer, as 
indicated in the authority clause in its header. 
Therefore, it can declassify the result and return 
it to the client. 

However, WebTax does not run with the au- 
thority of the client. This means that it cannot 
remove any of the client’s labels from the data, 
and therefore it is unable to leak the client’s 
information to the tax preparer. Furthermore, 
the client can determine this by simple inspec- 
tion of the header of WebTax; it is not necessary 
to read the code. 

For other programs, however, things aren’t so 
simple. For example, the bidders in the auction 
need to authorize the program to run with their 
authority so that it can let all of them know 
about the winning bid. Even so, less reading 
of code may be required because the code can 
be organized so that all declassification happens 
in the top level code. For example, even if the 
client of WebTax gave the program some au- 
thority (e.g., to release the name and address of 
the user to the tax preparer), it would be unnec- 
essary to examine the code of calcTax provided 
it did not run with the client’s authority, which 
can be determined by examining its header. 


4.2 Runtime Authority 


Jif is far more flexible than described in this 
paper; discussion of many of Jif’s features has 
been omitted for brevity. However, one feature 
of Jif that is particularly helpful to TEP is Jif’s 
ability to represent and reason about principals 
whose authority is unknown at compile-time. 
This feature makes it possible to protect dis- 
tinct participants in a TEP computation from 
accidentally sharing data when they have the 
same role, such as the bidders in an auction. 
Supporting these features requires some simple 
extensions to TEP, which are described here. 
Jif represents unknown authorities as runtime 
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principals, which are first-class values of type 
principal. Runtime principals can be used in 
labels and so can represent the role of a par- 
ticipant in a TEP computation. Participants 
whose labels contain runtime principals cannot 
be compared directly, and so cannot acciden- 
tally share data. 


When the authority of the participant needs 
to be known (eg. to do a declassification), the 
program must check whether the participant’s 
authority can be represented with a known 
static authority. Jif has two features that make 
this check possible: the ability to compare the 
authorities of static and runtime principals and 
the ability to determine the value of an unknown 
label. 


Runtime principals can be compared to static 
principals using an actsfor test in Jif. actsfor 
checks whether one principal is authorized to 
act on behalf of another, in which case the au- 
thorized principal can use the other’s authority. 
In an auction, each bidder is a distinct partic- 
ipant, but a static principal (such as bidder) 
must be authorized to declassify each bidder’s 
bid. An auction can use an actsfor test to 
check whether this authorization exists at run- 
time: if so, the declassification is allowed; other- 
wise, the auction must ignore that bidder’s bid. 
Although this may seem similar to the origi- 
nal auction model, this model limits the use of 
bidder’s authority to only the code where it is 
needed. Jif supports a similar runtime test for 
labels that provides similar benefits. 


To support Jif’s ability to represent and rea- 
son about runtime authority, TEP must be ex- 
tended in two ways. First, TEP must provide 
a way to represent principals at runtime. TEP 
does this by providing a class that stores the 
information about a runtime principal, such as 
the underlying participant’s public key. Second, 
TEP must provide a way to compare princi- 
pals. TEP does this using a principal hierar- 
chy, which is a data structure that represents 
the actsfor relation between principals. TEP 
can then determine whether one principal can 
act for another by searching for a path between 
those principals in the principal hierarchy. 


5 Prototype 


5.1 Model 


The prototype implementation of TEP is based 
on a design that uses a PKI, as described in 
Section 3.8.2. All policy decisions are made by 
TEP, rather than distributed to the participants 
(1]. The prototype both accepts certificate 
chains for policies [2] and supports on-demand 
policy generation using certificate-chain discov- 
ery [4, 1]. The prototype also automatically 
includes the invoker of a computation as one of 
the computation’s participants. 

The prototype is implemented entirely in 
Java and is available online [20]. While Java 
provides the benefits of type safety and ease 
of development, it results in significant perfor- 
mance degradation compared to native code. 
We believe that our design admits more efficient 
implementations and plan to demonstrate this 
in future work. 


5.2 Performance 


This section present performance results for two 
applications: empty, an empty application to 
test baseline invocation, and taz, a tax prepa- 
ration application. The experiments use three 
machines: one TEP server and two participants. 
Each machine is a 600MHz Intel Pentium II 
with 512MB RAM. Each runs RedHat Linux 
6.0 and Sun’s Java Runtime Environment 1.2.2 
with a just-in-time compiler. The machines 
communicate over 100Mb local Ethernet and 
use 1024-bit RSA keys for public-key cryptog- 
raphy. 


5.2.1 Empty 


In the empty application, an invoker connects to 
TEP, establishes a secure session, and requests 
a program by URL. TEP fetches the program, 
checks it using the standard Java bytecode ver- 
ifier, and executes the requested method (which 
is empty). 

The total time spent at the invoker is 185ms: 
148ms on cryptography for the secure ses- 
sion and 37ms communicating with TEP. TEP 
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spends 148ms on crypto and 35ms handling the 
request: 25ms waiting for the invoker to com- 
plete the session protocol and send its request; 
10ms fetching, loading, and verifying the pro- 
gram; and Oms executing the requested method. 

The vast majority of this time is spent on 
cryptography. Each secure channel creation re- 
quires one RSA decryption, encryption, signa- 
ture, and verification. On the test platform, 
1028-bit RSA private key operations take 71ms 
each and public key operations take 2ms each. 
The same operations in C++ on a 450MHz 
Celeron take 27ms and 0.7ms each, an improve- 
ment of over 60% [5]. Thus, a native code imple- 
mentation of cryptography can greatly improve 
the performance of the system. 


5.2.2 Tax 


The tax application involves two parties: the 
client (the invoker) and the tax preparer. The 
application reads income data from the client, 
opens a channel to the tax preparer, reads data 
from the preparer, calculates the result, and 
writes the result to the client. The preparer 
runs its own agent to accept connections from 
TEP, create secure sessions, and provide the 
data needed by the application. 

The total time spent at the client is 665ms: 
150ms on crypto, 25ms waiting for TEP to fin- 
ish the session protocol, 60ms waiting for TEP 
to load and start the application, and 430ms in- 
teracting with it. TEP spends 150ms on crypto 
and 450ms handling the request: 20ms loading 
the application and 430 ms running it. 

The tax application spends 180ms establish- 
ing a secure session with the tax preparer and 
170ms dynamically generating the policy that 
binds the preparer’s key to its channel name. 
The remaining 80ms are spent reading data 
from the participants and writing the result to 
the client. 

A large part of the application time is spent 
generating a policy using certificate-chain dis- 
covery. This time can be eliminated by caching 
policies ahead of time. Application providers 
and invokers can provide TEP with the certifi- 
cate chains needed to prove the required bind- 


ings, and thus improve performance. 


6 Related Work 


6.1 Secure Program Partitioning 


The most closely related work to ours is secure 
program partitioning, a technique that protects 
the privacy and integrity of data in shared com- 
putations by splitting programs among multiple 
hosts [26]. Whereas TEP assumes that there 
is a single host trusted by all participants, se- 
cure program partitioning supports heteroge- 
neous trust of the hosts used in the computa- 
tion. Both systems take advantage of static in- 
formation flow analysis and cryptographic tech- 
niques to provide privacy and integrity assur- 
ances. Both systems currently require that com- 
putations be configured statically at invocation, 
although future work promises greater flexibil- 


ity. 


6.2 Java Applets 


Java applets authorize programs by checking 
that the program is signed by a trusted provider 
[10]. This form of program authorization re- 
quires that the user decide what permissions 
to grant to code signed by a particular signer 
and only applies to code that runs on the lo- 
cal machine. In the TEP model, this sort 
of authorization is required to restrict par- 
ticipants’ application-specific agents to access- 
ing the network only through a trusted TEP- 
provided agent. 


TEP’s main advantage over the Java model 
is that a computation does not run locally to 
any participant in a computation, so no partici- 
pant gets access to the other participants’ data. 
It does not suffice to run a Java program on 
an arbitrary third-party server, since the server 
must provide the appropriate identification and 
isolation of the computation to ensure that data 
is not leaked. 
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6.3. Active Networks 


Active networks permit applications to inject 
programs into networks to deploy new network 
services [25, 24]. This system shares certain fea- 
tures with TEP: the ability to load new code 
dynamically and the need to isolate and control 
that code. 

When code is executed at an active node, it 
must use a restricted API to access the underly- 
ing system, much like TEP’s channel API. Ac- 
tive nodes use this API to regulate the code’s ac- 
cess to shared resources. TEP can be extended 
similarly to provide certain types of resource 
control. 


6.4 Secure Multiparty Computation 


Secure multiparty computation uses crypto- 
graphic techniques to run shared computations 
with minimal or no need for a trusted third 
party [6, 13]. Such techniques can reduce the 
amount of trust required of TEP, providing 
greater assurance for computation participants. 
However, these techniques often require a ma- 
jority of honest participants, while TEP does 
not. 

TEP’s main advantage over these techniques 
is flexibility. New applications for TEP are easy 
to develop, whereas no simple technique exists 
for developing new secure multiparty applica- 
tions. 


7 Conclusion 


We have presented TEP, a trusted third-party 
computation service. We began by identifying 
a set of requirements for such services and pre- 
sented a design that satisfies those requirements 
while maintaining generality. The design en- 
sures that each participant in a computation has 
enough information to determine if that compu- 
tation can leak its data. 

We then described an implementation of the 
design and demonstrated its flexibility with ex- 
amples. TEP supports programs written in 
Java that use channels, a general mechanism for 


communicating with the participants in a com- 
putation. TEP assigns roles to participants to 
aid in reasoning about computations and sup- 
ports client-side agents that can provide general 
interfaces to computations on TEP. 


We then improved the safety of the system 
by incorporating static information-flow analy- 
sis for TEP programs. TEP accepts programs 
written in Jif, a Java-based language that can be 
checked at compile-time for information leaks. 
We showed how the concepts in the Java version 
of TEP are represented in Jif and provided a Jif 
example to demonstrate the changes. Using Jif, 
TEP can guarantee the privacy of participants 
in certain computations without requiring that 
the participants inspect the code. 


Finally, we presented the performance for a 
prototype implementation of TEP. We showed 
that the prototype can run a simple third- 
party tax preparation application with reason- 
able performance. We found that the major- 
ity of the time for a computation is spent on 
the cryptography for creating secure channels. 
This suggests that optimizing the cryptography 
and channel protocol can greatly improve per- 
formance. 


Throughout this paper, we have identified 
ways in which TEP can be extended. The 
most fundamental of these is enabling partici- 
pants to initiate connections to computations on 
TEP. This allows TEP computations to act as 
servers for requests from participants. Another 
important extension is resource control: TEP 
can protect participants’ privacy but currently 
cannot withstand denial-of-service attacks from 
the programs it runs. A final extension is sup- 
port for Jif’s runtime mechanisms. These en- 
able programmers to create more general pro- 
grams for TEP that are guaranteed to protect 
participants’ privacy. 
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